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Description 

SOCIAL NETWORK SURFING 

Background of Invention 

[0001] Knowledge of a persorTs personal social relationships is 
extremely useful for many reasons. If one knows that they 
and a stranger have a common friend or colleague, they 
can approach this new person with significant common 
ground and a strong reference. One can also use the 
knowledge of another's social relationships to find partic- 
ular sorts of expertise. For example, if a first user was 
looking for help with particular type of technical patent, 
they could look up similar sorts of patents, determine the 
inventors and then see if any of the inventors were either 
close to them, or close to someone to whom they were 
close. 

[0002] How can one learn up to date information about a given 
user"s personal relationships using online re- 
sources?Buddy lists, like those provided by Lotus Same- 
time allow a given user to author lists of those to whom 
they are close, even enabling a given user to categorize 



these contacts. No teachings are provided allowing others 
to see this data. 

[0003] Searches for references to a given user, either as the au- 
thor of papers or as the inventor of particular patents, en- 
able one both to determine the given user"s fields of ex- 
pertise, and to learn others with whom the given user has 
collaborated an important form of relationship. Since the 
lists of collaborators generated in this way are formed au- 
tomatically, rather than being created and updated by the 
given user, one cannot know whether or not the given 
user is or was really close to anyone listed; all one can say 
is they both appeared as authors on one or more docu- 
ments. A buddy list does not guarantee this either, but is 
likely a better guideline to highly significant relationships. 

[0004] Analysis of email and chat group usage is another means 
of trying to determine the user"s personal relationships. 
Here too, one cannot be sure that the given user is actu- 
ally close to a second user simply because they sent or re- 
ceived mail from them. For example, the user might con- 
stantly receive a flood of unwanted email (SPAM) from a 
particular source, a source to whom they are far from 
close. Further, since such usage analysis is done asyn- 
chronously, the relationships revealed are not necessarily 



current. 

[0005] international publication number WO 01/050680 A3 de- 
scribes a system and method that provides a single ag- 
gregated list of all of their personal contacts, source in- 
cluding personal desktop portal users, instant messaging 
users, e-mail addresses, and cell phones. No teachings 
are provided allowing others to inspect this aggregated 
list. 

[0006] Services like Friendster (for details see 

http://www.friendster.com/info/moreinfo.jsp) provide 
online environments wherein given user can specify a par- 
ticular set users to whom they are close. Since this in- 
volves an external service, the people that can be included 
in the given user"s list are limited to other"s who are also 
service participants. Even if all of those that were impor- 
tant to the given user were service participants, the users 
would have to constantly manually update the service"s 
version of their relationship list to match that in their real 
life. 

[0007] Thus, there remains a need for a system and method that 
allows a second user to retrieve and inspect a dynamically 
updated social relationship collection of a first user, where 
the data sources for this relationship collection are appli- 



cations where inputs are made by the first user manually, 

but where the updates to the network-accessible version 

are made automatically. 
Summary of Invention 

[0008] An object of the present invention is to provide a method 
for allowing the sharing of social relationships collections 
including the step of creating a social relationship collec- 
tion object for a first user that provides access to at least 
one individual with whom they have a social relationship 
and allowing a second user to retrieve the social relation- 
ship collection object. As a result of allowing the second 
user to retrieve the social relationship collection object, 
the second user inspects a reference contained in the first 
user"s social relationship collection object. 

[0009] Various other objects, features, and attendant advantages 
of the present invention will become more fully appreci- 
ated as the same becomes better understood when con- 
sidered in conjunction with the accompanying drawings, 
in which like reference characters designate the same or 

similar parts throughout the several views. 
Brief Description of Drawings 

[0010] Fig 1 shows an example of the network topology accord- 



ing an embodiment of the present invention. 

[001 1] pig 2 shows an example of a component diagram of the 

server according an embodiment of the present invention. 

[0012] pig 3 shows an example of the server's logic according an 
embodiment of the present invention. 

[0013] Fig 4 shows an example of a component diagram of the 
client according an embodiment of the present invention. 

[0014] Fig 5 shows an example of the client's logic according an 
embodiment of the present invention. 

[0015] Fig 6a shows an example of an augmented buddy list ac- 
cording an embodiment of the present invention. 

[0016] Fig 6b shows an example of a retrieved, augmented buddy 
list according an embodiment of the present invention. 

[0017] Fig 6c shows an example of a mediated, augmented 

buddy list according an embodiment of the present inven- 
tion. 

[0018] Fig 7 shows an example of the overall method according 

an embodiment of the present invention. 
Detailed Description 

[0019] a detailed example of an embodiment of the current in- 
vention is given, describing how the current invention is 
used to allow a second user to retrieve and inspect the 
social relationship collection of a first user, this retrieval 



and inspection may be accomplished via a web browser 
communicating with a web-based (HTTP) social relation- 
ship collection server. 
[0020] pig. 1 depicts an example of a network topology of the 
preferred embodiment. As shown, there are three client 
nodes, CI, C2 and CN, 1010 through 1030, respectively 
(described in detail with reference to Figs 4 and 5), con- 
nected through network 1040 to server 1000 (described 
in detail with reference to Figs 2, and 3). The network 
1040 includes, but is not limited to the Internet, or an in- 
ternal intranet, or wireless or wired telecommunication 
network. Although only three client nodes 1010 1030 are 
pictured in Fig. 1, the current invention is applicable to 
any greater number as well. Also, note that although the 
preferred embodiment involves a TCP/IP-based network 
application, other forms of network communication are 
also applicable. 

[0021] The social relationship collections of the associated users 
of CI, C2 and CN, 1010 - 1030 are also shown in Fig. 1 
as Collection 1, Collection 2 and Collection N, 1050 1070, 
respectively. The network accessible image of each of 
these collections is shown as held within a data-store 
1080 in the Social Relationship Collection Server 1000, 



these represented by Collection 1 Image 1090, Collection 
2 Image 1100, and Collection N Image 1110, respectively. 
As will be described in detail with references to Fig. 2 5 
and 7, the collection images 1090 1110 held on the sever 
1000 are updated whenever necessary to match their 
real-life counterpart 1050 1070, respectively. 

[0022] pig 2 depicts a more detailed component diagram of the 
server node 1000, which manages all users" social rela- 
tionship collection images 1090 1110 and provides web- 
based access to them. This server 1000 can be any com- 
puting node able to act as an HTTP server. This includes, 
but is not limited to, the products sold by IBM under the 
trademarks ThinkPad or PowerPC, running the operating 
system and server application suite sold by Microsoft un- 
der the trademark Windows NT, or Linux. 

[0023] The server 1000 preferably includes a CPU 2000, a net- 
work interface 2010, a storage device 2020 such as a disk 
or DASD, and memory 2030, such as RAM. According to 
the present invention, the server logic 2035 (which will be 
discussed in more detail with reference to Fig 3), is 
preferably embodied as computer executable code that is 
loaded from remote source (e.g., over the network 1040 
via the network interface 2010), local permanent optical 



(CD-ROM), magnetic storage (such as disk), or DASD 2020 
into memory 2030 for execution by CPU 2000. The mem- 
ory 2030 preferably includes: An HTTP Server Handler 
2050 (discussed in detail with reference to Fig 3), A Server 
Relationship Collection Handle 2060, and A Server Rela- 
tionship Collection Database 2070. 

[0024] The Server Relationship Collection Database 2070 can be 
any application providing access and persistent manage- 
ment of data, such as that sold by IBM under the trade- 
mark DB/2. Those with regular skill in the art will also ap- 
preciate that the Server Relationship Collection Database 
2070 could be run on another remote network-connected 
node and accessed via the network 1040. 

[0025] pig 3 shows a detailed flow diagram of the server logic 
2040, i.e., the server's 1000 control flow. As shown, the 
server 1000 awaits input in step 3000, and then checks 
whether the input is an HTTP request in step 3010. If the 
input is such an HTTP request, then the input is checked 
in step 3020 to see if it is relationship collection-related. 
If it is, then Server Relationship Collection Handler 2060 is 
invoked, following which control continues at step 3000. 
If the input is not relationship collection-related, then 
HTTP Server Handler 2050 is invoked, following which 



control continues at step 3000. If the input is not an HTTP 
request, then a miscellaneous handler, beyond the scope 
of the current invention, is invoked in step 3030, follow- 
ing which control continues at step 3000. 

[0026] The Server Relationship Collection Handler 2060 manages 
all requests to create, modify and retrieve the social rela- 
tionship collection images 1090 1110 it holds in the 
Server Relationship Collection Database 2070. In the pre- 
ferred embodiment, all communication between this han- 
dler 2060 and clients is accomplished using HTTP (i.e., 
web-based) requests. There are two legal requests: Col- 
lection image updates, and Collection image retrievals. 

[0027] update requests include both a collection image and the 
associated user"s ID. The handler 2060 first checks if 
there is an entry for the given ID in the database 2070, 
creating one if not. The handler 2060 then writes the 
given collection image into this entry, overwriting previ- 
ous versions, if necessary. If successful, the handler 2060 
return an HTML document to the requesting client indicat- 
ing success. 

[0028] Retrieval requests contain only the ID of the target user. 
The handler 2060, first checks with the database to en- 
sure that there is an entry for the specified user ID, re- 



turning an error-indicating HTML document to the re- 
questing client if not. Once found, the handler 2060 gets 
the relevant collection image from the database 2070. 
Then, using the collection"s data, the handler 2060, builds 
an HTML document through which the user of the re- 
questing client can inspect the collection. 
[0029] one will appreciate a collection image request could also 
include the user ID of the requestor. With this data, the 
handler 2060 would be able to enforce access rights re- 
strictions (e.g., "Only Bob, Jane and Terese can access my 
collection."). 

[0030] one will also appreciate that collection images can contain 
access rights specifications, specifications either the 
database 2070, or the handler 2060 can check before re- 
turning collection image data to anyone. 

[0031] pig. 4 depicts a more detailed component diagram of the 
client network node 4000 used by clients, CI, C2 and CN 
1010 1030. For any participating user, their client ma- 
chine (i.e., one of 1010 1030) acts as both their relation- 
ship collection source (i.e., the source from which the col- 
lection images 1090 1110 are transmitted to the server 
1000), and their window into other users" relationship 
collections (i.e., via the HTML collection-renderings re- 



trieved from the server 1000 by their HTTP client 4060 
using HTTP). 

[0032] Examples of platforms that support the client 4000 in- 
clude, but are not limited to, an IBM ThinkPad running 
Windows 95 and a web browser such as Microsoft's Inter- 
net Explorer. Clients can also include network-con- 
nectable mobile (i.e., portable) devices such as that sold 
under the trademark WorkPad by IBM, as well as smart 
cellular telephones (i.e., devices which can act as a cellular 
telephone as well as run network applications, like web 
browsers), like that sold under the trademark Nokia 
90008 by Nokia. 

[0033] As shown in Fig. 4, a client node 4000, preferably include: 
A CPU 4010, A network interface 4020, A storage device 
4030 (e.g., a disk or DASD), and Memory 4040 (e.g., 
RAM). 

[0034] According to the present invention, the client logic 4050 
(which will be discussed in more detail with reference to 
Fig 5), is preferably embodied as computer executable 
code that is loaded from a remote source (e.g., over the 
network 1040 via the network adapter 4020), local per- 
manent optical (CD-ROM), magnetic storage (such as 
disk), or DASD 4030 into memory 4040 for execution by 



CPU 4010. The memory 4040 preferably includes: An 
HTTP Client 4060 (e.g., a web browser), and A Client Rela- 
tionship Collection Handler 4070 (discussed in detail with 
reference to Fig. 5), and A Client Relationship Collection 
Database 4080,The HTTP Client, being any type of web 
browser, can include but is not limited to the product sold 
by Microsoft under the trademark Internet Explorer, or 
that sold by Opera Software for smart phone and personal 
data assistants (PDAs). 

[0035] The Client Relationship Collection Database 4080 can be 
any application providing access and persistent manage- 
ment of data, such as that sold by IBM under the trade- 
mark DB/2. Those with regular skill in the art will also ap- 
preciate that the Client Relationship Collection Database 
4080 could be run on another remote network-connected 
node and accessed via the network 1040. 

[0036] pig. 5 shows a detailed flow diagram of the clients" logic 
4050. In the preferred implementation, the client"s logic 
4050, as depicted in Fig. 5, the client 4000 awaits input in 
step 5000. Once received, the input is checked to see 
whether it is a relationship collection modification in step 
5010. Such modifications include any user initiated event 
that directly results in a change of one or more of the 



user"s social relationship collections. Such events include, 
but are not limited to the user: Modifying their buddy list 
(e.g., Sametime or AOL Instant messenger), Modifying 
their personal address book (e.g., Lotus Note"s address 
book), Creating or modifying the user list or access rights 
on one or more of their personal computing devices (e.g., 
creating a user account for a close coworker, giving them 
read, write, and execute rights to the user"s home direc- 
tory). 

[0037] | n eac h case, the Client Relationship Collection Handler 
4070: Retrieves the necessary information from the given 
client 4000, Updates the given user"s relationship collec- 
tion (e.g., Collection 1 1050), stored in the Client Rela- 
tionship Collection Database 4080, and then Updates the 
server 1000 image of the client's relationship collection 
(e.g., Collection 1 Image 1090) using an HTTP request, 
one containing both the user"s ID and the new, updated 
relationship collection. 

[0038] one will appreciate that in addition to actual relationship 
entries (e.g., references to particular individuals) a given 
user"s relationship collection can contain instructions 
specifying the sources of the relationship data, as well as 
descriptions of how the data is to be retrieved. A given 



user, for example could specify that they want both the 
entries from their Sametime buddy list and from their per- 
sonal Lotus Notes address book used as relationship data 
sources. Given this directive, any modification to either of 
the user"s buddy list or address book would constitute a 
relationship modification and would have to be processed 
by the Client Relationship Collection Handler 4070. 
[0039] one will also appreciate that a given user can also specify 
access rights in their relationship collection, rights that 
will enforced by the Server Relationship Collection Handler 
2060. E.g., a user can specify that only requests with par- 
ticular user IDs are allowed to retrieve their relationship 
collection. Similarly, a user can specify that particular user 
IDs are not allowed to retrieve their relationship collec- 
tion. 

[0040] one further will appreciate that a given user can segment 
their relationship collection, e.g., into work-related con- 
tacts and family- related contacts, and then provide sepa- 
rate access rights for each segment. E.g., only members of 
my department (specified via a set of user IDs) are allowed 
to retrieve my work-related social collection segment, 
while only family members are allowed to retrieve my 
family- related social collection segment. 



[0041] After completion of the Client Relationship Collection 
Handler 4070 control resumes at step 5000. 

[0042] if the input is not a relationship collection modification, 
then step 5020 checks whether it is the user making an 
HTTP request. If so, the HTTP Client 4060 is invoked, fol- 
lowing which control continues at step 5000. One such 
HTTP-based request could be a request from the server 
1000 by one user for another user"s relationship collec- 
tion image (e.g., 1110). Examples of the web pages re- 
trieved by the client 4000 will be discussed in detail with 
references to Figs. 6a, 6b and 6c. 

[0043] if the input is not an HTTP request, then a miscellaneous 
handler, beyond the scope of the current invention, is in- 
voked in step 5030, following which control resumes at 
step 5000. 

[0044] pigs 6a, 6b and 6c all depicts web pages (HTML docu- 
ments) retrieved by a client's HTTP client 4060 from the 
server 1000. One with regular skill in the art will appreci- 
ate that other client server architectures are also applica- 
ble, including, but not limited to client and server applica- 
tions using TCP sockets for communication (for details, 
see Douglas Comer, Internetworking with TCP/IP, Vol. 1 
Principles, Protocols and Architecture. Prentice Hall, En- 



glewood Cliffs, New Jersey, 1991). 

[0045] pig. 6a shows an example of a user"s social relationship 
collection after it has been retrieved from the server 1000 
and rendered by the client's HTTP Client 4060. As shown 
the web page 6000 includes a title 6010 indicating the ID 
of the associated user"s ID, "Peter,"and two sections indi- 
cated by titles "Collaborators ,, 6020 and "Watching Peter" 
6050. The first section 6020 contains two references 
"Jane"6030 and "John. "6040, as does the second section 
6050: "Betty"6060 and "Bob"6070. 

[0046] Three of the references 6030, 6040 and 6070 are in bold, 
while the fourth 6060 is in italics. Those with regular skill 
in the art and familiar with Sametime Buddy Lists will ap- 
preciate this is meant to indicate that while the users cor- 
responding to 6030, 66040 and 6070 are currently active, 
the fourth user 6060, is not. 

[0047] unlike a standard Sametime buddy lists, three of the four 
references have social relationship collection icons 6080, 
6090 and 6100 to their right. When one these icons is se- 
lected, the social relationship collection for the corre- 
sponding user is retrieved. Thus, if one selected 6080, the 
social relationship collection for Jane would be retrieved 
and displayed. This might be a useful way of getting a 



hold of a co-worker who you know is a close associate of 
one of your buddies, perhaps to serve as a surrogate for 
your buddy, or for other ends. 

[0048] with reference to any privacy issues, users may have the 
option of making their relationship collection visible to all, 
to only those in their relationship collections, to only peo- 
ple in their workgroup, or to only those who have also 
made their relationship collections visible, etc. 

[0049] Another alternative would be to allow people to designate 
whether a particular entry would be viewable by others. 
This could allow a person to designate others to go to for 
various sorts of help, e.g., "For help on Loops, contact 
Wendy" "For info about the Conference Call Proxy, contact 
Tracee". 

[0050] The Fig. 6a also adds a new (automatic) category 6050 

that is denoted by the title "Watching Peter.'This category 
6050 shows who currently has the user in their relation- 
ship collections. Thus, Betty and Bob both have Peter in 
their relationship collections. In theory, this seems fair; 
people being observed could certainly argue they have a 
right to know who is watching. On the other hand, it 
might undermine current usage by making a "watcher" ac- 
countable for who and why they are observing someone. 



[0051] one might imagine various ways of extending this idea, 
by, for example, having a category of "those who have 
watched me in the last week,"and so on. 

[0052] one way of lessening the impact of making watching ex- 
plicit would be to provide a mechanism that allowed peo- 
ple to register their intent. Thus, we might imagine cate- 
gories such as "lt"s useful to know when you'Ve around," 
or other categories such as Td like to have a short chat 
with you, at your convenience." This is undoubtedly a 
cumbersome way of embodying this functionality, but de- 
spite that the idea of using IM to register interest in an in- 
teraction some time in the future (or even at a particular 
time in the future) could be worth exploring. 

[0053] pig. 6b shows the rendering 6200 of the social relation- 
ship collection retrieved when Jane"s relationship collec- 
tion icon 6080 is selected. As shown, the web page 6200 
contains: A title 6210 indicating Jane as the owner of the 
collection; Two sections, "Current Project" 6220 and 
"Watching Jane"6250, The first section 6220 containing a 
reference to "Yuki"6230, The second section containing 
references to both "Peter"6260 and "Bob"6270; and The 
references to Yuki 6230, Peter 6260, and Bob 6270 having 
social relationship collection icons 6280, 6290 and 6300 



associated with them, respectively. 

[0054] Another response to the privacy concerns raised above is 
to replace the user IDs or those referenced with some sort 
of description: possible manually assigned by the collec- 
tion owner, or automatically drawn from online sources, 
such as personal pages or organizational hierarchy charts. 
Fig. 6c shows one example or a modified version of Fig 6b 
with section names anonymized and user names replaced 
by short descriptions of expertise or position. Thus, while 
the web page 6400 still has title 6410 indicating that the 
Jane is the owner of the collection, "Current Project"6220 
is now "<category 1>"6420, "Yuki" 6230 is now "<Project 
manager>"6430, "Watching Jane"is now <category 
2"6450, "Peter"6260 is now "<Java, C+ + , Perl>"6460, and 
"Bob"6270 is now "<UI design>" 6470, and all of the so- 
cial relationship collection icons are gone. Here, to contact 
Bob, a given user e-mail Jane and say "I see a Ul design 
expert in your buddy list. ..would you tell me who they are 
and perhaps introduce me?" Not shown, but nevertheless 
imaginable, might be some sort of ID # (or simply <entry 
N in category M>) which could be passed to Mathew to al- 
low him to quickly identify to whom you are referring. 

[0055] As alternative approach, instead of surfing your buddies" 



social relationship collections, one could instead define 
search criterion and select which of your buddies to 
search. 

[0056] pig 7 shows a detailed flow diagram of the overall social 
relationship collection management process 7000. First, 
in step 7010, the process awaits a relevant event. When an 
event is received, it is check in step 7020 to see if it con- 
cerns the modification of some user"s social relationship 
collection. If so, then in step 7030 Client Relationship 
Collection Handler 4070 of the associated user"s client 
4000 updates the users collection, storing the updated 
collection in the relevant client's 4000 Client Relationship 
Collection Database 4070. Next, in step 7040 the Client 
Relationship Collection Handler 4070 sends an update re- 
quest to the server 1000. In step 7050, the server's 1000 
Server Relationship Collection Handler 2060 updates the 
relevant collection image, storing it in the Server Relation- 
ship Collection Database 2070, following which control 
continues at step 7010. 

[0057] if the event is not a collection modification, then it is 

checked in step 7060 to see if it is a collection request. If 
not, control continues at step 7010. If it is, then in step 
7070 the requesting client's HTTP client 4060, send a re- 



quest to the Server 1000. In step 7080, the server's 1000 
Server Relationship Collection Handler 2060 retrieves the 
requested collection image and then returns in to the re- 
questing client. Finally, in step 7090, the relevant client's 
4000 HTTP Client 4060 renders the returned collection for 
the requesting user to inspect. Following this, control 
continues at step 7010. 

[0058] The current invention also provides methods where a first 
organization could employ and support the social rela- 
tionship collection surfing techniques just described to a 
second organization. 

[0059] First, one with regular skill in the art will appreciate that a 
first organization could enable a member of a second or- 
ganization to surf social relationship collections. This pro- 
vision includes determining the number of users that 
would be using the service, configuring a server 1000, 
and then installing the server 1000. The second organiza- 
tion would also have to ensure that members of the sec- 
ond organization had the required clients 4000 to interact 
with the current invention, upgrading the existing hard- 
ware and software if necessary. 

[0060] The first organization could also administer one or more 
aspects of the social relationship collection surfing infras- 



tructure. This support could include ensuring that proper 
operation of the server 1000 and all operating clients 
4000, even checking that both the server 1000 and the 
clients 4000 have sufficient resources for their Server Re- 
lationship Collection Database 2070 and the Server Rela- 
tionship Collection Databases 4080, respectivelyA first or- 
ganization could also train members of a second organi- 
zation to use the social relationship collections surfing 
methods and system provided by the current invention. 
This training could include explanation of how to restrict 
access to ones social relationship collections, and how 
user can set up select the data sources that will be used to 
determine their relationship collection (e.g., Sametime 
buddy list and personal address book). 

[0061] a first organization could also support a second organiza- 
tion'^ use of the user ID replacement technique described 
with reference to Fig. 6c. This support could include the 
first organization'^ determining what online personal in- 
formation sources the second organizations has, and then 
configuring the server 1000 to use these sources when- 
ever user ID replacement is selected by a given user. 

[0062] | t j S t0 De understood that the provided illustrative exam- 
ples are by no means exhaustive of the many possible 



uses for the invention. 

[0063] From the foregoing description, one skilled in the art can 
easily ascertain the essential characteristics of this inven- 
tion and, without departing from the spirit and scope 
thereof, can make various changes and modifications of 
the invention to adapt it to various usages and conditions. 

[0064] | t j S t0 De understood that the present invention is not 

limited to the embodiments described above, but encom- 
passes any and all embodiments within the scope of the 
following claims: 



